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Scheduled to launch in September 2014 atop a Delta IV Heavy from the 
Kennedy Space Center, the Orion Multi-Purpose-Crew- Vehicle (MPCV’s) 
maiden flight dubbed “Exploration Flight Test -1” (EFT-1) intends to stress the 
system by placing the uncrewed vehicle on a high-energy parabolic trajectory 
replicating conditions similar to those that would be experienced when returning 
from an asteroid or a lunar mission. Unique challenges associated with 
designing the navigation system for EFT-1 are presented in the narrative with an 
emphasis on how redundancy and robustness influenced the architecture. Two 
Inertial Measurement Units (IMUs), one GPS receiver and three barometric 
altimeters (BALTs) comprise the navigation sensor suite. The sensor data is 
multiplexed using conventional integration techniques and the state estimate is 
refined by the GPS pseudorange and deltarange measurements in an Extended 
Kalman Filter (EKF) that employs the UDU T decomposition approach. The 
design is substantiated by simulation results to show the expected performance. 

INTRODUCTION 

In 2006, commissioned under the administration of President George W. Bush, 
Lockheed Martin was awarded the prime contract to develop the next generation man- 
rate spacecraft called the Orion Crew Exploration Vehicle (CEV) to ferry astronauts to 
the Low Earth Orbit (LEO), service the International Space Station (ISS) and bolster deep 
space exploration by returning humans back to the moon and eventually taking them to 
Mars and beyond. The venture initially fell under the auspices of an umbrella program 
known as the Constellation, which was later scrubbed by the Obama administration. After 
surviving through a period of uncertainty that is not uncommon amidst an administration 
change, the scope of the Orion project was redefined to primarily focus on deep space 
exploration. Shifting work scope eclipsed by political turmoil precipitated a name change 
from Orion CEV to Orion Multi-Purpose Crew Vehicle (MPCV). 
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Political challenges aside, Orion faces a host of technical challenges given the 
diversity of environments the spacecraft needs to survive. One such challenge is being 
able to successfully re-enter the Earth’s atmosphere and land safely. As a risk mitigation 
maneuver, in 2010 the project decided to add an uncrewed multi-hour, two orbit test 
called the Exploration Flight Test-1 (EFT-1) to the flight manifest. The EFT-1 trajectory 
features a highly elliptical second orbit to replicate high-energy re-entry conditions 
similar to those that would be experienced when returning from an asteroid. At its 
farthest point Orion would be approximately 5908 km (3671 miles) above the surface of 
the Earth. Figure 1 depicts the notional mission profile for EFT-1. 
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Figure 1: EFT-1 Mission Profile 

NAVIGATION ARCHITECTURE 
Sensor Manifest for EFT-1 

Orion will ultimately be a two-fault tolerant vehicle before it is certified as man- 
rated. However, the two-fault tolerance requirements were relaxed to just one-fault 
tolerant for the uncrewed EFT-1 mission. A minimal sensor suite consisting of two Orion 
Inertial Measurement Units (OIMUs), a GPS receiver (GPSR) and three baro altimeters 
(BALTs) was selected to satisfy the navigation requirements. The sensors chosen for 
EFT-1 are intended to serve as the building blocks for future missions, though many of 
the Fault Detection, Isolation and Response (FDIR) algorithms will be revised as the two- 
fault tolerance requirements are re-introduced and more sensors are added. 

The OIMUs provide high-rate accelerometer and gyro data for translational and 
rotational state propagation, respectively. The propagated state is updated by GPS 
pseudorange (PR) and deltarange (DR) measurements. Early in the design cycle the 
decision was made to process raw PR and DR measurements rather than using the GPSR 
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derived Position, Velocity and Time (PVT) solution. Though there is more complexity 
associated with ingesting PR and DR measurements, this approach offers more 
robustness by allowing the EKF to be more selective with each measurement. PR/DR 
measurement processing over PVT also affords more design flexibility by allowing the 
EKF to process GPS updates even if there are less than four satellite vehicles (SVs) being 
tracked by the GPSR. 5 The baseline configuration for EFT-1, however, is to not process 
GPS measurements unless there are at least five SVs available. 

Contrary to most conventional spacecraft, the EFT-1 vehicle lacks an external 
attitude reference source, i.e. there is no star tracker in the sensor manifest. Instead the 
attitude is initialized on the pad via a process called ground alignment 6 and propagated 
using the high-rate gyro data. The EKF employs a unique method to refine the attitude 
state estimate by coupling the translational and rotational state dynamics. In the presence 
of non-conservative acceleration the attitude state partials become observable with 
respect to GPS measurements. 

Although the BALT data is not directly processed by the EKF, BALTs offer 
redundancy during the Entry, Descent and Landing (EDL) sequence. In the event the 
GPSR fails or the EKF is unable to process GPS measurements during re-entry, the FDIR 
logic autonomously selects the BALT output as the primary source of altitude. The logic 
accomplishes this by comparing the EKF covariance in the radial direction with a 
parameterized threshold value. Obviously this feature is only available when the BALT 
outputs are valid which only occurs at low-altitudes — approximately below 22.9 km (or 
about 75,000 ft). 

Figure 2 exhibits the data flow from the sensors to the User Parameter Processing 
(UPP) block. The UPP serves as the “one-stop-shop” for all navigation outputs that are 
provided to downstream consumers. 


5 In order for a GPSR to calculate a valid PVT solution it must have line-of-sight to at least four SVs. 

6 Ground alignment is analogous to gyro-compassing 
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Figure 2: Sensor Data Flow 


Processing Rate of Navigation Algorithms 

The EFT-1 navigation algorithms are divided into two rate-groups: 1) 40Hz and 
2) 1Hz. The 40Hz processing is intended to support the needs of downstream consumers 
by propagating the state at high-rate. In contrast the 1Hz processing is primarily reserved 
for the processing of the GPS data. 

Navigation Channels 

The concept of a navigation channel was developed to provide the capability to 
“hot-swap” the state estimate in the event a failure occurred. A channel is directly tied to 
an OIMU meaning Channel 1 and Channel2 correspond with OIMU1 and OIMU2, 
respectively. Within a channel exists an IMU Sensor Operating Procedure (IMUSOP) 
Computer Software Unit (CSU) that is responsible for parsing the OIMU data, a Coarse 
Align (CAlign) CSU that is responsible for providing a crude estimate of the initial 
attitude on the pad, a Filtered Navigator (FIFT) CSU that is responsible for multiplexing 
the OIMU data with the GPS updates and an Inertial Navigator (INRTF) CSU that is 
responsible for maintaining an un-aided (OIMU-only) state. Figure 3 provides a 
schematic representation of the 40Hz processing. INRTF and FIFT CSUs have 
counterparts on the 1Hz side. The Inertial Navigator Gravity (InrtlNavGrav) and EKF 
CSUs on the 1Hz side provide a higher-order gravity estimate to INRTF and state 
updates to FIFT, respectively. 
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Figure 3: Navigation Channel Concept 


The outputs of both Channel 1 and Channel2 are tunneled into the Post-Channel 
block where the Navigation FDIR (NAVFDIR) CSU selects the primary state. The 
NAVFDIR scheme relies on the IMUFDIR outputs and augments the selection criteria 
with a few checks on the filtered state. One of the checks it relies on is the percentage of 
PR/DR measurements being accepted by each channel. 

EKF Design 

The measurements used in the Orion EKF are Integrated Velocity (IV), GPS 
pseudorange, and GPS deltarange. On the pad, the Integrated Velocity measurement is 
used for IMU alignment/gyrocompassing, this measurement is not used the rest of the 
mission and consists in a measured change in ECEF position of zero. The GPS antennas 
are obscured by the Launch Abort System shroud and therefore the GPS measurements 
are not available until several minutes into the ascent once the shroud is jettisoned. The 
GPS pseudorange and deltarange are used for the remainder of the mission. 

A high-fidelity mission simulation called Osiris was utilized for tuning the Orion 
EKF. Osiris uses a TRICK environment running the actual flight software in a variety of 
dispersed Monte Carlo scenarios. 

The Orion filter design uses 24 Exponentially Correlated Random Variable 
(ECRV) parameters to estimate the accelerometer/gyro misalignment and 
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nonorthogonality. By design, the time constant and noise terms of these ECRV 
parameters were set to manufacturer specifications and not used as tuning parameters. 
They are included in the filter as a more analytically correct method of modeling 
uncertainties than ad-hoc tuning of the process noise. Tuning is explored for the powered- 
flight ascent phase, where measurements are scarce and unmodeled vehicle accelerations 
dominate. On orbit, there are important trade-off cases between process and measurement 
noise. On entry, there are considerations about trading performance accuracy for 
robustness. Process Noise is divided into powered flight and coasting flight and can be 
adjusted for each phase and mode of the Orion EFT-1 mission. Measurement noise is 
used for the IV measurements during pad alignment. It is also used for the pseudorange 
and deltarange measurements during the rest of the flight. 

As described previously, the IMU error states are modeled as ECRV states in the 
filter, so they are tuned using a process noise and time constant. The noise values were 
taken from the component specifications, and the time constants were chosen as two 
hours (for the IMU biases) and four hours (rest of the IMU error states) to be roughly 
constant over the duration of the EFT-1 mission. The other filter values to tune were the 
measurement underweighting, velocity process noise, angular process noise, and 
measurement weights. In general, the process noise was tuned by propagating the filter 
without measurements and ensuring the resulting error growth was bounded by the 
predicted uncertainty. The measurement noise was considerably more difficult to tune, 
because the measurements themselves were heavily time correlated especially the 
pseudoranges. This is due to a poor ionosphere correction model and lack of low- 
elevation satellite masking. 

The filter tuning performance was analyzed for a closed loop End-to-End mission 
scenario. The position components are most impacted by GPS atmospheric errors, while 
the velocity components are most affected by unmodeled accelerations and IMU model 
errors. There is still ongoing investigation into the velocity error signature as it is 
suspected this may be an artifact of unrealistic accelerations supplied by the simulation 
from the trajectory dynamics file. 

SIMULATION RESULTS 

This section contains the results of 90 Monte Carlo runs of a complete mission, 
from pre-launch to landing. These runs confirm the validity of the chosen parameters. 
Figure 4 shows the performance of the usual eleven states (position, velocity, attitude, 
GPS receiver clock bias and drift) as well as the performance of the IMU error states. In 
these plots, the green section is the coarse align, the orange is the fine align, the first blue 
segment is ascent, the pink section is orbital flight, and the final blue section is entry and 
landing. 
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Figure 4: End-to-End Performance 


Prelaunch 

This is the phase prior to launch when the vehicle is on the pad. The only 
measurement used during fine- align mode is integrated velocity (IV). The pseudorange 
(PR) and delta range (DR) measurement types are not used during this phase. The main 
purpose of fine align is to better estimate the attitude and the IMU states, therefore none 
of these states are considered and they are all estimated. 

During fine align the OIMUs sense the opposite of gravity which is a large 
acceleration. The accelerometer threshold is the same for all flight phases and its value is 
determined during tuning of the orbit phase. The velocity random walk of the 
accelerometer is very small, therefore the translational process noise is small and 
dominated by the unmodeled gravity. The angular process noise is chosen from the 
gyro’s angular random walk spec value. The GPS clock bias and drift noises are chosen 
from the expected clock physical properties. The coast values for the process noise are 
not used in this phase; they are only used during the orbit phase. The values are kept the 
same across flight phases and tuned for orbit. 

Figure 5 shows the performance of 450 Monte Carlo runs in a Launch Hold 
scenario which transitions back to fine align for a longer hold prior to launch. It 
demonstrates the choice of parameters provides reasonable performance even in the 
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worst-case alignment conditions. In this scenario the initial position error on the pad is 
dispersed. The attitude, position, and velocity are all shown to be well bounded for the 
entire duration of the alignment and launch hold. 
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Figure 5: Prelaunch Performance 


Ascent 

The ascent phase is divided in two parts, the first when GPS measurements are 
not enabled, and the second when they are. The only difference between Fine Align and 
Ascent Without GPS is that IV measurement processing flag is set to zero in the latter. 
Integrated velocity (IV) is only used on the pad, while GPS measurements (PR and DR) 
are utilized during this phase. To date there is no simulation or any other evidence that 
attitude or IMU state estimation would corrupt the EKF solution. Therefore none of these 
states are considered and they are all estimated. The maximum number of processable 
measurements is set to 12 which is a large enough number to obtain sufficient 
performance while keeping the flight computer throughput reasonably low. To avoid 
possible transient issues the first PR measurement is not processed. After a long blackout 
the covariance becomes very large and the nonlinearity of the DR measurement creates 
convergence issues. Through numerical simulation it was determined that allowing for 
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multiple PR (30s) to be processed before incorporating a DR mitigates this issue because 
the PRs shrink the uncertainty before DRs are introduced. If a satellite is not present for a 
single cycle, the counters are not reset and if the satellite comes back is immediately used 
as a measurement. If the satellite is absent for more than a cycle the counters are reset. 

PR and DR noise standard deviations are obtained from GPSR performance. The 
numbers are kept high to include residual ionosphere error. A larger residual edit 
threshold is used to compensate for the higher noise values. While we allow for the usage 
of the PR variance output from the GPS receiver, the EKF has a PR variance floor that 
will almost always prevent us from using the GPS receiver output value except in the 
case of very large values. Underweighting is applied when the estimated measurement 
has an uncertainty greater than 100ft. 

For the EFT-1 mission we want to test GPS clock stability, clock filter state 
restarts, and high altitude GPS processing, so we do not want to exercise a GPS clock 
reset using the clock bias re-initialization timer. Therefore, this value is set to a number 
larger than the expected duration of the mission. 

Initial uncertainty of the clock bias and drift are obtained from GPSR 
specifications. When accelerating fast under the chutes the attitude dynamics is not 
accurately represented by the 4Hz IMU buffer. Therefore PR and DR are inhibited above 
a certain angular velocity, the values are determined from simulation analysis. 

A deltarange timing threshold of 1.5 seconds prevents the flight software from 
trying to incorporate a DR measurement using two non-consecutive PR measurements 
(GPS measurements are available at 1Hz). 

Figure 6 shows the performance of 450 Monte Carlo runs, this is a nominal 
scenario to demonstrate the choice of parameters provides good performance. These runs 
are performed without dispersing the GPS constellation in order to obtain the same set of 
measurement for each Monte Carlo run. As before, the errors seem well bounded and 
convergence times are reasonable. 
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Figure 6: Ascent Performance 


Orbit 

The accelerometer bias is constant for a particular trajectory, but random across 
an ensemble of trajectories. To obtain a worst-case estimate we take three times the 
standard deviation of the bias, and treat the result as a constant. Each error source applies 
to each component of the velocity. We assume that the velocity white noise and the 
velocity random walk are independent. The same GPS parameters are used during orbit 
as are used during ascent. The only change is that a slightly lower value is used for the 
underweighting coefficient. 

Figure 7 illustrates the performance of 450 Monte Carlo runs. This is a nominal 
scenario to demonstrate that the choice of parameters provides good performance. These 
runs are performed without dispersing the GPS constellation in order to obtain the same 
set of measurement for each Monte Carlo run. Although some of the errors lie outside the 
three-standard deviation bounds estimated from the filter’s covariance matrix, this is a 
nominal condition. The errors quickly converge to values within the requirement for 
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accuracy of estimation of on-orbit position and velocity. The acceleration models in the 
trajectory simulation file are suspected to not match the velocity, so the oscillating error 
behavior is likely at least partially due to this inconsistency. 
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Figure 7: Orbit Performance 


Entry 


Figure 8 shows the performance of 450 Monte Carlo runs, this is a nominal 
scenario to demonstrate the choice of parameters provides good performance. These runs 
are performed without dispersing the GPS constellation in order to obtain the same set of 
measurement for each Monte Carlo run. 
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Figure 8: Entry Performance 


CONCLUSIONS 

This paper presents the design of the absolute navigation architecture and fdter for 
the Orion Exploration Flight Test I mission. There are still some aspects of the filter 
tuning and simulation environment that are under investigation. The oscillating velocity 
error signature during Low Earth Orbit is suspected to be at least partially due to 
numerical issues with the input trajectory file. Future implementations of the filter design 
will include masking of GPS signals with high ionospheric interference, which should 
mitigate the position excursions outside the 3a filter uncertainty. In spite of this future 
work, to date the filter’s performance has been proven robust and sufficient to meet 
mission requirements in both high fidelity simulation and hardware-in-the-loop testing. 
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